home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-mhsds-convert-01.txt
< prev
next >
Wrap
Text File
|
1993-07-08
|
10KB
|
364 lines
Network Working S.E. Kille
Group ISODE Consortium
INTERNET-DRAFT July 1993
Expires: January 1994
MHS use of Directory to support MHS Content Conversion
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
Abstract
User Agents have various capabilities for support of multimedia
messages. To facilitate interworking between UAs of differing
capabilities, it is useful for the MTS to be able to perform content
conversion. This document specifies an approach for X.400 Message
Handling Systems to perform application level routing using the OSI
Directory in order to support content conversion. This document
assumes MHS use of directory to perfom routing accoreding to ``MHS use
of Directory to support MHS Routing'' [1].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
INTERNET--DRAFT MHS Content Conversion July 1993
1 Protocol Extensions
A number of protocol extensions are needed, primarily to support
content conversion. These extensions may be used with either MTA
Abstract Service (P1) or MTS Abstract Service (P3). The per-recipient
extensions are given in Figure 1.
The following per-recipient extensions are defined.
general-explicit-conversion The explicit conversion of X.400 only
allows for a listed set of conversions. This attribute allows for
any conversion of body parts to be requested. Built in EITs must
be represented by their object identifiers.
content-conversion This requests for different content types to be
converted (e.g., content type 22 to 2 downgrade).
source-route This gives a sequence of points (either MTAs or MDs)
which must be traversed in the order given. The points may be
accessed directly or indirectly for each step. This should be
stripped as each point is reached. If this element is marked as
critical for transfer, the route is mandatory, otherwise it is
advisory. There is some risk of spurious loops being detected.
This can be specified by a UA or an MTA. An MTA may introduce
further source routing if a need arises.
route-barring This gives a list of points which must not be
traversed. If this element is marked as critical for transfer,
the barring is mandatory, otherwise it is advisory.
route-restriction This give a list of points which the route must be
restricted to (e.g., to constrain costs).
The following per-message extensions are defined in Figure 2. These
are:
warning-interval Some MTAs offer a facility to send (IPMS) warnings
about a messages delayed transit. This parameter allows the
warning interval to be specified.
last-warning This parameter specifies the time at which the last
warning was sent. It will ensure that warnings are sent to the
Kille Expires: January 1994 Page 1
INTERNET--DRAFT MHS Content Conversion July 1993
_______________________________________________________________________
general-explicit-conversion EXTENSION
GeneralExplicitConversion
::= id-general-explicit-conversion
GeneralExplicitConversion ::= SEQUENCE {
from ExternalEncodedInformationType,
to ExternalEncodedInformationType }
content-conversion EXTENSION
ContentConverson 10
::= id-content-conversion
ContentConversion ::= SEQUENCE {
from ContentType,
to ContentType }
source-route EXTENSION
SourceRoute
::= id-source-route
20
SourceRoute ::= SEQUENCE OF RouteElement
RouteElement ::= CHOICE {
mta [0] DistinguishedName,
md [1] DistinguishedName }
route-barring EXTENSION
RouteBarring
::= id-route-barring
30
RouteBarring ::= SET OF RouteElement
route-restriction EXTENSION
RouteRestriction
::= id-route-restriction
RouteRestriction ::= SET OF RouteElement
_____________Figure_1:__Per-recipient_Protocol_Extensions______________
Kille Expires: January 1994 Page 2
INTERNET--DRAFT MHS Content Conversion July 1993
_______________________________________________________________________
warning-interval EXTENSION -- interval between user warnings
INTEGER -- in minutes
::= id-warning-interval
last-warning EXTENSION -- time last warning was send
UTCTime
::= id-last-warning
______________Figure_2:__Per-message_Protocol_Extensions_______________
originator at even intervals.
2 Format Conversion
An MTA will determine reformatting requirements for a message in two
ways:
1. First, any explicitly requested conversions will be dealt with
2. Second, the recipients capabilities are determined (from the
directory), and any necessary conversions made. UA capability may
be determined from any of:
o The User's entry
o The O/R Address entry
o A subtree capability restriction as defined in [1].
A choice to do reformatting can only be made by an MTA with access
to this information. Once an MTA has determined a requirement to
do reformatting, it should attempt to do this. If this cannot be
done, or if the requirements are unknown, the message should be
routed without conversion.
In many cases, the MTA will be able to perform conversion locally. In
some cases, particularly simple MTAs, it may be necessary to perform a
conversion at a remote MTA. First the remote MTA must be identified.
Each MTA will maintain a list of MTAs (or MDs??) it uses for
performing remote conversions. Any MTA offering conversions will
Kille Expires: January 1994 Page 3
INTERNET--DRAFT MHS Content Conversion July 1993
_______________________________________________________________________
mTAUsedForConversion ATTRIBUTE
WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
::= at-mta-used-for-conversion
bodyPartConversionService ATTRIBUTE
WITH ATTRIBUTE-SYNTAX GeneralExplicitConversion
::= at-body-part-conversion-service
contentConversionService ATTRIBUTE
WITH ATTRIBUTE-SYNTAX ContentConversion 10
::= at-content-conversion-service
______________Figure_3:__Format_Conversion_Registration________________
register them in the directory. Thus it is a matter of simple
matching to determine if one of the MTAs used for conversion services
offers the conversion needed (perhaps in more than one stage). The
attributes needed to do this are defined in Figure 3.
The attributes defined are:
mTAUsedForConversion This defines the set of MTAs which are used by
an MTA to provide conversion.
bodyPartConversionService This defines the services offered by an MTA
for body part conversion.
contentConversionService This defines the services offered by an MTA
for content type conversion (e.g., 22 to 2 downgrade).
This facility can be used for either body part conversion or content
type conversion.
In some cases, the MTA performing the conversion will be accessed
indirectly. In this case, a mandatory source route should be
specified, in order to ensure that the message is routed to the
correct MTA.
References
[1] S.E. Kille. MHS use of the directory to support MHS routing, July
Kille Expires: January 1994 Page 4
INTERNET--DRAFT MHS Content Conversion July 1993
1993. Internet Draft.
3 Security Considerations
Security considerations are not discussed in this INTERNET--DRAFT .
4 Author's Address
Steve Kille
ISODE Consortium
PO Box 505
London
SW11 1DX
England
Phone: +44-71-223-4062
EMail: S.Kille@ISODE.COM
DN: CN=Steve Kille,
O=ISODE Consortium, C=GB
UFN: S. Kille, ISODE Consortium, GB
Kille Expires: January 1994 Page 5
INTERNET--DRAFT MHS Content Conversion July 1993
A Object Identifier Assignment
_______________________________________________________________________
mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
enterprises(1) isode-consortium (453) mhs-ds (7)}
conversion OBJECT IDENTIFIER ::= {mhs-ds 7}
oc OBJECT IDENTIFIER ::= {routing 1}
at OBJECT IDENTIFIER ::= {routing 2}
id OBJECT IDENTIFIER ::= {routing 3}
10
oc-conversion-mta OBJECT IDENTIFIER ::= {oc 1}
at-body-part-conversion-service OBJECT IDENTIFIER ::= {at 1}
at-content-conversion-service OBJECT IDENTIFIER ::= {at 2}
at-mta-used-for-conversion OBJECT IDENTIFIER ::= {at 3}
id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}
id-content-conversion OBJECT IDENTIFIER ::= {id 2}
id-general-explicit-conversion OBJECT IDENTIFIER ::= {id 3}
id-logging-level OBJECT IDENTIFIER ::= {id 4} 20
id-route-barring OBJECT IDENTIFIER ::= {id 5}
id-route-restriction OBJECT IDENTIFIER ::= {id 6}
id-source-route OBJECT IDENTIFIER ::= {id 7}
id-last-warning OBJECT IDENTIFIER ::= {id 8}
id-warning-interval OBJECT IDENTIFIER ::= {id 9}
_______________Figure_4:__Object_Identifier_Assignment_________________
Kille Expires: January 1994 Page 6